Справочный центр ALD Pro 3.2.1
Создание дополнительных параметров групповых политик¶
Функционал групповых политик¶
Групповые политики позволяют снизить стоимость управления ИТ-инфраструктурой за счет автоматического применения одинаковых настроек на больших группах компьютеров, имеющих общее целевое назначение.
Каждая политика (в терминах MS AD объект групповой политики) представляет из себя именованный набор параметров, в соответствии с которыми производится автоматическая настройка операционной системы и прикладного программного обеспечения.
Для создания и настройки групповой политики нужно выполнить следующие действия:
создать новую групповую политику
добавить конфигурационный параметр в политику (включить его)
установить желаемые значения атрибутов для параметра
назначить политику на подразделение, внутри которого есть целевые компьютеры или пользователи
подождать от 30 минут до 80 минут или изменить таймер для получения и применения политики
Администраторам доступны сотни параметров «из коробки», которые соответствуют настройкам панели управления ОС Astra Linux. Но для решения частных задач конкретного бизнеса может потребоваться разработка дополнительных параметров силами команды внедрения, и в ALD Pro для этого есть все необходимые инструменты.
Версионность¶
Каждая политика ГП имеет версию, которая автоматически изменяется, если наступило одно из следующих событий:
Внесены любые изменения в политики ГП или связанный с ней дополнительный параметр ГП. В этом случае дата изменений - это дата, когда пользователь внес изменения. А автор - это ФИО пользователя, внесшего изменения.
Произошло обновление версии ALD Pro. В этом случае дата изменений - это дата обновления системы. В этом случае «автором» изменений будет указано Системное обновление.
На основании параметра версионности standalone-minion принимает решение использовать при применении ГП сохраненные значения параметров, или запрашивать новые у службы каталогов.
Как работают групповые политики¶
Для получения данных групповых политик и их применения используется pull-модель. Инициатором работы является миньон SaltStaсk (standalone-minion), установленный на каждом компьютере домена, который по протоколу LDAP к серверу службы каталогов получает актуальные данные о групповой политике.
Миньон Standalone — это рабочие станции или серверы, на которых работает демон-миньон Salt, обладающий широкой функциональностью, работающий автономно от мастера. Используется для запуска заданий в системе без подключения к мастеру.
Важно
Получение данных групповых политик и применение политик с помощью standalone-миньона реализовано с версии ALD Pro 2.2.0, ранее для этих задач использовался стандартный миньон SaltStack, который получал данные от мастера.
Подробнее о работе групповых политик указано в Руководство Администратора. Часть 2 → Портал управления. Настройка и работа → Групповые политики → Групповые политики → Создание групповой политики или в Справочном центре ALD Pro.
Как создать дополнительный параметр¶
Привилегия |
Описание |
На что распространяется |
|---|---|---|
Computer Group Policy Additional Parameters Catalog - Read |
Привилегия позволяет:
|
На весь домен |
User Group Policy Additional Parameters Catalog - Read |
Привилегия позволяет:
|
На весь домен |
Computer Group Policy Additional Parameters - Manage |
Привилегия позволяет:
|
На весь домен |
User Group Policy Additional Parameters - Manage |
Привилегия позволяет:
|
На весь домен |
Параметр групповой политики (в терминах MS AD шаблон групповой политики) подобен классу из теории объектно-ориентированного программирования. Он определяет модель для создания объектов конфигурирования, описывая их свойства (атрибуты) и методы для работы с этими данными (скрипт). Продолжая аналогию из ООП, «объектом» в данном случае будет являться экземпляр параметра, добавленный в конкретную групповую политику.
Параметр может быть «простым» или «составным»:
В случае простого параметра свойства представляют из себя плоский список атрибутов. Например, для настройки межсетевого экрана может потребоваться задать уровень детализации журнала, и эта настройка подразумевает одно конкретное значение, поэтому она может быть реализована атрибутом «простого» параметра.
Составные параметры позволяют задавать массив списка атрибутов, где в каждом списке представлен однотипный набор данных. Если продолжать пример с межсетевым экраном, то для настройки фильтрации может потребоваться разрешить входящие ssh-соединения, запретить исходящие smtp и т.п., поэтому такие настройки нужно реализовывать атрибутами «составного» параметра.
Параметр может быть «параметром компьютера» или «параметром пользователя». «Параметры компьютеров» отвечают за настройку оборудования и служб вне зависимости от того, какой пользователь работает с системой. «Параметры пользователей» отвечают за настройку рабочей среды пользователя вне зависимости от того, на каком компьютере он работает. В обоих случаях скрипты выполняются с возможностями по администрированию root-пользователя.
Чтобы создать новый параметр групповой политики нужно перейти на страницу Управление доменом → Доп. параметры групповых политик и выбрать одну из вкладок:
Рисунок 48 Как создать дополнительный параметр 1¶
Рисунок 49 Как создать дополнительный параметр 2¶
На каждой вкладке по умолчанию будет представлен корневой Каталог дополнительных параметров, внутри которого вы можете создавать свои пользовательские параметры. Если параметров станет слишком много, вы сможете группировать их по подразделам.
Выберите раздел Каталог дополнительных параметров, нажмите кнопку [+ Новый параметр] и заполните карточку следующими значениями:
Раздел «Основные»
Название параметра: «Диспетчер задач htop». Это название, которое будет отображаться в каталоге при редактировании групповых политик на портале управления.
Уникальный идентификатор: «software_htop». Это название, которое будет использоваться в качестве имени
\*.slsфайла на диске и в скриптах SaltStack. Формируется по следующей формуле:rbta_ldap_custom_gp_host_+ введенные пользователем данные «software_htop». Для пользователейrbta_ldap_custom_gp_user_.Тип каталога: «Параметр компьютерной групповой политики». Определяет, относится ли данный параметр к настройкам компьютера или пользователя. Параметр не доступен для редактирования, его значение определяется автоматически в зависимости от того, с какой страницы вы перешли к созданию дополнительного параметра.
Тип параметра: «простой». Определяет вид параметра. Простой - простой список атрибутов, Составной - массив списка атрибутов.
Папка параметра: «Дополнительные параметры». Указывает раздел каталога, в котором будет доступен данный параметр.
Назначение параметра: «Управление установкой и настройкой диспетчера задач htop». Текстовое описание, позволяющее указать наиболее важную информацию о работе параметра для удобства последующего использования. Данный текст отображается при редактировании групповой политики по нажатию кнопки вопроса. Здесь же можно внести данные о требованиях к ОС (см. Руководство Администратора. Часть 1 – Общие сведения – Планирование ресурсов).
Разделы Атрибуты параметра и Конфигурация скрипта станут доступны при редактировании сохраненного параметра.
Особенности редактирования дополнительных параметров ГП¶
Для редактирования дополнительного параметра групповых политик нужно перейти на страницу Управление доменом → Доп. параметры групповых политик → Параметры компьютеров или Параметры пользователей → “Имя параметра” и внести нужные изменения, сохранить.
Чтобы эти параметры синхронизировались с групповыми политиками и применились на компьютерах и пользователях нужно перейти на карточку этих политик Групповые политики → Групповые политики → “Имя политики”, внести изменения и сохранить. Изменения в групповой политике приведут к повышению ее версии. Только после этого изменения дополнительных параметров ГП будут применены на компьютерах и для пользователей. Или принудительно применить политику (подробнее читайте в Отладка).
Аналогичные действия необходимо применить если дополнительный параметр групповой политики был удален.
Как настроить атрибуты дополнительного параметра¶
Атрибуты — это свойства, которые можно задавать при добавлении параметра к групповой политике. Например, если мы создадим параметр для управления диспетчером задач htop на рабочих станциях, то нам понадобится атрибут «Должен быть установлен», чтобы в зависимости от его значения устанавливать или удалять указанное программное обеспечение.
Рисунок 50 Как настроить атрибуты дополнительного параметра¶
Атрибуты представляют из себя обычные текстовые строки, значение которых может быть интерпретировано в скриптах в том числе как числа, логические значения ($true и $false), списки и т.п. Добавьте атрибут:
Название атрибута: «Должен быть установлен»
Название, под которым будут видеть этот атрибут на карточке параметра.
Уникальный идентификатор: «must_be_installed»
Идентификатор атрибута, который будет использоваться как имя переменной в SaltStack скриптах.
Описание: «атрибут используется как логическая переменная true / false для ветвления шаблона»
Краткие комментарии для инженера, которые помогут упростить поддержку этого атрибута в будущем, когда потребуется внести какие-либо изменения. Данная информация недоступна при настройке групповой политики, поэтому, если вы хотите дать подсказку администратору о возможных значениях этого атрибута, внесите эту информацию в описание параметра.
Обязательный:
true
Пользователь должен указать значение атрибута
Уникальный:
true
Применяется для составных параметров, у которых возможны конфликты. Для разрешения конфликтов для каждого параметра нужно определить уникальный атрибут. В рамках одного ГПО нельзя будет создать массив списка атрибутов с одинаковыми значениями уникального параметра.
Скрипт дополнительного параметра¶
Скрипты SaltStack похожи на PHP, в них текст перемежается императивными инструкциями языка программирования, по результату выполнения которых получается итоговый документ. За императивную часть отвечают инструкции шаблонизатора Jinja2, а декларативная часть задается по правилам SaltStack в YAML-подобном синтаксисе.
Императивные инструкции шаблонизатора Jinja¶
Инструкции языка Jinja внедряются с помощью фигурных скобок:
{% … %}- синтаксис для вставки инструкции языка шаблонизатора Jinja. Аналог PHP:<? … ?>{% print(…) %}- пример инструкции для вывода в документ по месту вызова значения выражения. Аналог PHP:<? echo (…) ?>{{ … }}- краткий синтаксис для вывода в документ по месту вызова значения выражения. Аналог PHP:<?= … ?>{### … #}- синтаксис для вставки комментариев средствами языка Jinja2. Аналог PHP:<?/* … */?>
Для повышения читабельности кода управляющие структуры обычно оформляют отступами, но yaml-документы крайне чувствительны к пробелам, поэтому данный инструмент форматирования оказывается недоступен без применения специальных операторов подавления отступов. Чтобы убрать лишние пробелы и пустые строки вам нужно всего лишь поставить знак дефиса слева, справа или с обоих концов управляющего блока:
{%-- удаляет пробелы и пустые строки слева;-%}- удаляет перенос текущей строки и переносит ее на предыдущую;{%-и-%}- удаляет пробелы и пустые строки слева, в т.ч. перенос текущей строки, поэтому текст окажется в конце предыдущей строки.
Внимание
При сохранении скрипта может появится предупреждение: «Ошибка конфигурации скрипта. Игнорировать ошибку и сохранить изменения?». Встроенный механизм проверяет соответствие указного скрипта формальным правилам, поэтому если есть уверенность, что скрипт корректный необходимо выбирать «Да» для сохранения.
Выполнение команд¶
Создайте файл hello.sls с простейшим Jinja-скриптом, чтобы проверить, как это работает, и выполните его с помощью команды aldpro-salt-call с указанными параметрами:
echo '{% do salt.log.info("Hello world!") %}' > hello.sls
aldpro-salt-call --local --file-root = . state.sls hello
Несколько комментариев:
Оператор «do» вызывает метод
salt.log.infoс параметром „Hello world!“Команда
aldpro-salt-callотвечает за локальное исполнение скриптов на миньонах.Параметр
localисключает обращение к мастеру для получения настроек.Параметр
file-rootсо значением «.» устанавливает в качестве рабочего каталога текущую директорию.Параметр
state.slsуказывает на то, что следует использовать метод sls модуляsalt.modules.state, который применяет состояния, описанные в одном и более файлов на диске из рабочей директории.Параметр
helloзадает имя файлаhello.sls, которое должно быть указано без расширения файла.
Еще один пример. С помощью метода run модуля cmd можно выполнить на удаленном хосте любую команду bash:
echo '{% do salt.cmd.run("apt-get install htop") %}' > installhtop.sls
aldpro-salt-call --local --file-root = . state.sls installhtop
Полный перечень всех модулей SaltStack можно найти на странице документации: https://docs.saltproject.io/en/latest/ref/modules/all/index.html
Работа с переменными¶
Переменные на языке Jinja задаются оператором set. Вам доступен широкий перечень типов данных: булевые, числовые, текстовые, списки, кортежи, словари:
{% set boolean_val = True %}
{% set int_val = 777 %}
{% set string_val = 'hello' %}
{% set list_val = ['h', 'e', 'l', 'l', 'o'] %}
{% set tuple_val = ('h', 'e', 'l', 'l', 'o') %}
{% set dict_val = { b: True, i: 777, s: 'hello') %}
При работе с числовыми переменными доступны обычные математические операторы:
{% set a = 5 %}
{% set b = 10 %}
{% set a = a + b %}
{% set b = a - b %}
{% set a = a - b %}
Конкатенация строк возможна как специальным оператором «~», который предварительно конвертирует все значения в строки, так и обычным оператором сложения «+»:
{% set a = 5 %}
{% set b = 10 %}
{% set c = a ~ b %}
{% set d = 'World' %}
{% set e = 'Hello, ' + d %}
Для выполнения более сложных преобразований над переменными доступно множество функций, которые можно применять как методы через точку или в стиле конвейеров bash через символ вертикальной черты, за что их так же называют фильтрами:
{% set a = 'Hello'.upper() %}
{% set b = 'world' | upper %}
Полный перечень встроенных фильтров Jinja можно найти в документации: https://jinja.palletsprojects.com/en/2.11.x/templates/#list-of-builtin-filters
Ветвления и циклы¶
Если выполнение набора команд должно зависеть от некоторого условия, то ветвление можно задать с помощью операторов if/elseif/else/endif:
{% if ram >= 2048 %}
...
{% elseif ram <= 4096 %}
...
{% else %}
...
{% endif %}
Циклы for являются аналогом конструкций типа foreach других языков программирования и предназначены для выполнения заданного набора инструкций применительно к каждому элементу из списка:
{% set users = ['ivanov', 'petrov', 'kuznetsov'] %}
{% for user in users %}
{% do salt.log.info(user.upper()) %}
{% endfor %}
Если нужно обработать данные словаря, используется метод items(), чтобы получить список его элементов:
{% set users = {'u1':'ivanov', 'u2':'petrov', 'u3':'kuznetsov'} %}
{% for id, user in users.items() %}
{% do salt.log.info(user.upper()) %}
{% endfor %}
Так как циклы Jinja работают только со списками, то для эмуляции обычных циклов со счетчиком вам нужно воспользоваться функцией range([min], max). Если передать этой функции один параметр, то будет сгенерирован список с указанным количеством элементов, нумерация которых будет начинаться с нуля. Если передать два числа, то нумерация элементов будет в указанном диапазоне:
{% do salt.log.info('Обратный отсчет') %}
{% for i in range(0, 10) %}
{% do salt.log.info(10 - i) %}
{% endfor %}
Информация о целевой системе (grains)¶
При написании скриптов Jinja можно опираться на информацию о целевом хосте, на котором этот скрипт будет применен. Данная информация доступна в словаре grains, тут находится информация об операционной системе, памяти, дисках, настройках сетевых интерфейсов и многом другом. Например, используя ключ nodename можно получить имя хоста:
{% set node = salt['grains.get']('nodename') %}
Актуальное содержание словаря grains для конкретного хоста можно посмотреть с миньона утилитой aldpro-salt-call:
aldpro-salt-call grains.items
local:
----------
astra_version:
----------
distr:
orel
version:
1.7.2
...
Более подробную информацию о модулях grains можно найти в документации по проекту: https://docs.saltproject.io/en/latest/ref/modules/all/salt.modules.grains.html
Передача информации с мастера (pillar)¶
При настройке групповых политик администраторы задают значения атрибутов, которые доменным компьютерам передаются через механизм пилларов (salt pillar, соляной столб). Актуальное содержание словаря pillar можно посмотреть с миньона утилитой aldpro-salt-call.
Для компьютеров:
aldpro-salt-call pillar.get aldpro-hosts:pc-1.ald.company.lan
Для пользователей:
aldpro-salt-call pillar.get aldpro-users:<логин пользователя>
Содержание словаря определяется тем, какие политики назначены конкретному компьютеру (условный аналог GPResult в MS AD). Данные пиллара доступны только тем миньонам, для кого они предназначены, поэтому через атрибуты можно передавать в том числе конфиденциальную информацию, например пароли служебных учетных записей, сертификаты.
Если же нужно проверить, была ли уже применена конкретная политика на хосте, можно применить состояние с параметром test=True. Если по результатам выполнения команды появится сообщение “No changes needed to be made”, значит система уже получила pillar с заданной групповой политикой:
aldpro-salt-call state.apply rbta_ldap_env_vars_h test=True
...
ID: /etc/bash.bashrc
Function: file.blockreplace
Result: True
Comment: No changes needed to be made
...
Более подробную информацию о модулях pillar можно найти в документации по проекту: https://docs.saltproject.io/en/latest/topics/tutorials/pillar.html
Создание файлов на стороне миньона¶
Есть методы для создания файлов touch, переименования rename, удаления clean. Подробное описание возможностей доступно на странице:
Декларативные описания SaltStack¶
Декларативная часть скрипта описывает в YAML-формате желаемую конфигурацию компьютера. В структуре документа указано, какие методы нужно вызывать для конфигурирования системы, и с какими параметрами. В качестве примера создадим файл software.sls со скриптом, который описывает состояние, после применения которого в системе должен стать доступен диспетчер задач htop:
cat software.sls
software_htop: ### Имя состояния
··pkg.installed: ### Вызов метода installed модуля pkg
····-·pkgs: ### Аргументы метода installed
······-·htop ### Значение аргумента pkgs
Можно выполнить скрипт с помощью команды:
aldpro-salt-call --local --file-root = . state.sls software
Подробное рассмотрение параметров команды:
local— означает локальную обработку без обращения к мастеру;file-root=.— устанавливает рабочую директорию, в которой будет выполняться поиск *.sls файлов;state.sls— указывает, что следует использовать модуль sls, который отвечает за применение состояний из файлов на диске;software— указывает имя *.sls файла без расширения.
Язык YAML, также как и JSON, является языком разметки текста для сериализации данных. Каждая строка задает пару ключ-значение, между которыми стоит знак двоеточия. Ключи могут состоять из одного и более слов, причем, заключать их в кавычки необязательно. В качестве значений поддерживаются как скалярные типы данных (int, float, boolean, string), так и вложенные словари, что позволяет создавать древовидные структуры данных. Второй и последующий уровни дерева должны обозначаться отступами с помощью двух и более пробелов, использовать символы табуляции вместо пробелов недопустимо. Если требуется прокомментировать какой-то фрагмент документа, то слева от комментария нужно поставить символ решетки.
На верхнем уровне структуры данных должен быть указан ключ с именем состояния, например, software_htop. Имя выбирается произвольно, в одном документе может быть описано несколько состояний, но их имена не должны повторяться.
На второй строке указано, что требуется вызвать метод installed модуля salt.states.pkg. Данный модуль является модулем состояния, т. е. его методы приводят систему к требуемому состоянию, описывая желаемый конечный результат, а не то, как к нему прийти. Есть также модули исполнения, которые выполняют в системе конкретные действия, ранее был приведен пример с использованием метода run модуля cmd для выполнения bash команды.
На третьей и четвертой строке методу передается аргумент pkgs со значением htop. Важно обратить внимание, что аргумент и его значение являются элементами списков, поэтому в начале этих строк стоит символ дефиса.
Отладка¶
Скрипт дополнительного параметра сохраняется в сервере службы каталогов ({корень} → cn=etc → cn=aldpro → cn=vcsStorage → cn=grouppolicy → cn={Идентификатор ГП}) и при получении по протоколу LDAP кешируется на миньоне в папках вместе с остальными групповыми политиками:
Параметры компьютеров:
/srv/aldpro-salt/roots/states/policies/host-policies/Параметры пользователей:
/srv/aldpro-salt/roots/states/policies/user-policies/
В соответствии с расписанием из файла /srv/aldpro-salt/roots/_modules/utils.py скрипты выполняются при запуске службы aldpro-salt-minion и по расписанию каждые 30 минут + от 5 до 50 минут случайного времени. Другими словами политики гарантировано применятся в течение 80 минут. Посмотреть текущее значение таймера можно командой:
aldpro-salt-call schedule.show_next_fire_time build_gp_pillars
При необходимости можно локально изменить время стационарного таймера (по умолчанию 30 минут):
В файле на клиентском компьютере:
/srv/aldpro-salt/config/minion.d/standalone_scheduler.conизменить значение атрибутаseconds/minutesв блоке интересующего задания. Для групповых политик этоbuild_gp_pillars.В файле
/srv/aldpro-salt/_modules/utils.pyзаменить_25_MINUTES = dt.timedelta(minutes=25). Выставлять значения таймера менее 10 минут нежелательно, это может привести к повышению нагрузки и на контроллер домена и на доменный компьютер.Перезапускаем миньон командой:
systemctl restart aldpro-salt-minion.service
Другой способ применения групповых политик: можно на миньоне вручную ввести команду (аналог gpupdate /force):
aldpro-salt-call state.apply gpupdate.gp
Можно в конце команды добавить pillar='{“force”: True}' - принудительное удаление связанного с политикой кэша. pillar='{“verbose”: True}' нужен для получения логов выполнения заданий применения. Использовать рекомендуется осторожно, поскольку вызывает повышенную нагрузку на контроллер домена.
Применить отдельно политики пользователя можно командой:
aldpro-salt-call state.apply policies.user-policies pillar="{'user': 'username'}"
Для работы с политиками пользователей нужно явно передавать имя пользователя, чьи настройки вы хотите применить pillar=“{'user': 'username'}”.
Требования к скриптам и наследование параметров¶
С 2.2.0 архитектура ALD Pro в части работы групповых политик изменилась, скрипты групповых политик получают только те компьютеры и пользователи, которым назначена политика. В связи с этим в скрипте может не быть проверки на назначение параметра конкретному компьютеру или пользователю.
Если на один компьютер или пользователя назначено несколько политик, использующих один и тот же параметр, то значения простых параметров будут переопределяться, а значения составных параметров суммироваться (см. Полезные инструкции → Наследования и суммирование групповых политик).
Миньон получает политики, назначенные на компьютер или авторизованного на компьютере пользователя. ALD Pro анализирует назначенные параметры, снизу вверх по дереву подразделений, оставляя только те которые соответствуют требованиям к операционной системе. Из оставшихся в результате операций суммирования и наследования формирует единый словарь pillar. Скрипты групповых политик отрабатываются миньоном только один раз с итоговым содержанием словаря pillar, вне зависимости от того, сколько раз соответствующий параметр был использован в объектах групповых политик, назначенных на этот компьютер или пользователя.